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Mail Stop AF 

Commissioner for Patents 

P.O. Box 1450 

Alexandria, VA 22313-1450 



Dear Sir: 



The Applicant requests review of the final rejection in the above-identified 
application, stated in the final Office Action mailed on August 13, 2009 (Final Office 
Action) with a period of reply through November 13, 2009. No amendments are being 
filed with this request. This request is being filed with a Notice of Appeal. The review is 
being requested for the reasons stated on the attached sheets. 

REMARKS/ARGUMENTS 



Claims 1-31 are pending in the instant application. Claims 1, 18, 24 and 29 are 
independent. Claims 29-31 are rejected under 35 USC 101 for allegedly directing to 
non-statutory subject matter. Claims 1-4, 15-20 and 23 are rejected under 35 USC 
102(e) as anticipated by USP 6,226,680 ("Boucher"). Claims 10 and 11 are rejected 
under 35 USC 103(a) as being unpatentable over Boucher, as applied to claim 1 above, 
and further in view of USPP 2002/0198934 ("Kistler"). Claims 12-14 are rejected under 
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35 USC 103(a) as being unpatentable over Boucher, as applied to claim 1 above, and 
further in view of Microsoft Winsock Direct and Protocol Offload on SANs, 03/03/2001 
("Microsoft"). Claim 21 is rejected under 35 USC 103(a) as being unpatentable over 
Boucher, as applied to claim 18 above, and further in view of Official Notice ("ON"). 
Claim 22 is rejected under 35 USC 103(a) as being unpatentable over Boucher, as 
applied to claim 18 above, and further in view of USPP 2002/0041566 ("Yang"). Claims 
5-8 and 24-28 are rejected under 35 USC 103(a) as being unpatentable over Boucher, 
as applied to claim 1 above, and further in view of USPP 2003/0046330 ("Hayes"). 
Claim 29-31 are rejected under 35 USC 103(a) as being unpatentable over Boucher, 
and further in view of Callaghan (NFS over RDMA) ("Callaghan"). 

I. Rejection to Claims 29-31 under 35 U.S.C. § 101 

Claim 29 recites "A unified driver, comprising: a computer program executable on a 
computer system, having at least one code section causes the computer system to 
perform steps comprising: executing said at least one code section from said unified 
driver in said computer system to handle..." The Examiner (see Final Office Action in page 
4) alleges that the driver comprises mere program codes, and does not comprise hardware 
elements in that computer system. The Applicant respectfully disagrees, and points out that 
claim 29 recites that the unified driver executes the program codes in the computer 
system . In this regard, the driver program codes are tied to the computer system, which also 
cause the computer system to perform the recited steps. Therefore, the Applicant maintains 
that the recited unified driver is statutory subject matter and is patentable. The Applicant 
respectfully requests that the rejection to claim 29 under 35 USC 101 be withdrawn. Likewise, 
claims 30-31 depend from claim 29, and are submitted to be also patentable. 



II. Examiner's Response to Arguments in the Final Office Action and the 
Advisory Office Action 

A. The Applicant argued that Boucher does not disclose or suggest at least the 
limitation of "...the processor operable to process a plurality of different types of network 
traffic, wherein each of said plurality of different types of network traffic 
corresponds to a different network protocol ," as recited in the Applicant's claim 1 . 

The Examiner (see Final OA in page 6) relied on Boucher's flow chart (step 59) in 
Fig. 3 (see Boucher col. 6 lines 33-55), which identifies the packet being a fast path or 
slow path candidate based on the packet header bytes which denote particular 
protocols. In other words, the Examiner alleges that the fast path packet header 
protocol and the slow path header protocol denote different network traffic types . 

The Applicant respectfully disagrees, and points out that MPEP 2141.02-VI 
states that "prior art must be considered in its entirety, including disclosures that teach 
away from the claims". Namely, the Applicant refers the Examiner to another portion of 
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Boucher's disclosure, which contrasts the above allegation of the Examiner. For 
example, Boucher states the following: 

"In effect, the fast-path replaces the states that are traditionally found in several 
layers of a conventional network stack with a single state machine encompassing all 
those layers, in contrast to conventional rules that require rigorous differentiation and 
separation of protocol layers. The host retains a sequential protocol processing 
stack which can be employed for setting up a fast-path connection or processing 
message exceptions. The specialized micro-processor and the host intelligently choose 
whether a given message or portion of a message is processed by the microprocessor or 
the host stack." 

See Boucher col. 3, line 60 - col. 4, line 3 (emphasis added). Boucher discloses 
that the fast-path processing is a replacement of the traditional protocol stack 
processing path. Furthermore, Boucher also discloses that the host retains the 
same protocol stack processing for setting up a fast-path connection for future 
processing of the fast-path packets or to the message exceptions. In other words, 
there is no difference in terms of "network traffic type" between Boucher's fast- 
path candidate packet and the traditional slow-path candidate packet. Boucher 
discloses that both the fast-path candidate packet and the slow-path candidate packet 
are of the same "offload" network traffic type, but may be processed with different 
paths for the purpose of processing efficiency only, and not because of different 
network traffic types, as alleged by the Examiner. 

Accordingly, Boucher's disclosure of the particular protocol indicated by the 
header bytes in the respective packets, are for identifying which path the packet 
may be routed for efficient processing. This is further evidenced by Boucher's Fig. 
4D, which illustrates that a fast path candidate may be processed by the traditional 
slow-path in an exceptional case. Contrary to the Examiner's allegation, if 
Boucher's fast-path candidate packet's header protocol indicates a different 
network traffic type than the slow-path protocol network traffic type, how could 
the fast-path protocol network traffic type be recognized and processed by the 
traditional slow-path protocol stack in the host (which allegedly only processes 
the slow-path traffic network protocol)? Therefore, based on the above rationale, 
the Applicant maintains that the Examiner's interpretation that Boucher's fast-path 
candidate packet is of a different network traffic type than the traditional slow-path 
candidate packet, is in fact, contrary to Boucher's disclosure. 

The Examiner (see Final Office Action in page 2) also argued that Boucher's 
disclosure of "determining whether the packets packet has header bytes denoting 
particular protocols, such as (TCP/IP or SPX/IPX)" constitutes "different types of 
network traffic" (see Boucher at col. 6, lines13-32). The Examiner is again referred to 
the Applicant's above arguments, namely, that Boucher discloses that the fast-path 
processing is merely a replacement path for efficiency purposes only , and not 
because it is a different network traffic type . The fast-path candidate packet can 
equally be processed by the slow-path protocol stack which allegedly only processes 
the slow-path header protocol. In this regard, the Examiner's above argument that the 
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(TCP/IP or SPX/IPX)" constitutes "different types of network traffic", is moot. Moreover, 
the Examiner is also referred to Applicant's argument (see 6/15/09 response in pages 
11-13), that Boucher discloses that the TCP/IP or SPX/IPX are protocols of different 
versions, but they still belong to the same TCP network traffic type (See Boucher 
at col. 6, lines13-32). 

Based on the foregoing rationale, the Applicant maintains that Boucher does not 
disclose or "...the processor operable to process a plurality of different types of network 
traffic, wherein each of said plurality of different types of network traffic 
corresponds to a different network protocol ," as recited in the Applicant's claim 1. 
Likewise, independent claim 18 is similar in many respects to claim 1, and therefore is 
also submitted to be allowable. The Applicant respectfully requests that the rejection of 
independent claims 1 and 18 under 35 U.S.C. § 102(e) be withdrawn. 

B. The Applicant specifically challenged the perceived and explicit assertions of 
Official Notice with regard to dependent claim 21, namely, "...time division 
multiplexing to determine which of the different types of network traffic access the 
software services via the single data path " is well known in the art. In response, the 
Examiner (see Final Office Action in page 4) stated the following: 

"TDM is a type of multiplexing in which two or more signals or bit streams are 
transferred apparently simultaneously as sub-channels in one communication 
channel, but are physically taking turns on the channel. The time domain is divided into 
several recurrent timeslots of fixed length, one for each sub-channel. Given that TDM is 
so well known in the art, it would have been obvious for one skilled in the art at the time 
of the invention to combine the teachings of Boucher and what is well known in the art to 
determine which of the different types of network traffic at which timeslot to 
access the data path by allotting multiple traffic segments of different types over 
one channel in different time slots using TDM in order to minimize cost and 
complexity of building multiple channels unnecessarily." 

The Examiner in effect, argued that TDM is well known for time multiplexing in a 
single channel, for transfer of two or more signals or bit streams. However, 
Applicant's claim recites "time division multiplexing to determine which of the different 
types of network traffic access the software services via the single data path ". In 
other words, the claimed TDM is for accessing software services via the single 
channel, and not for transfer of signals or bit streams, as alleged by the Examiner. 
In this regard, the Applicant maintains that TDM is not well known for " accessing 
software services via the single channel," as recited in Applicant's claim 21 . 

The Applicant maintains all remaining arguments regarding allowability of the 
independent and dependent claims, stated in the 6/15/09 response to Final Office 
Action. 
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CONCLUSION 



Based on at least the foregoing, the Applicant believes that all claims 1-31 are in 
condition for allowance. If the Examiner disagrees, the Applicant respectfully requests a 
telephone interview, and requests that the Examiner telephone the undersigned Patent 
Agent at (312)775-8093. 

The Commissioner is hereby authorized to charge any additional fees or credit 
any overpayment to the deposit account of McAndrews, Held & Malloy, Ltd., Account 
No. 13-0017. 

A Notice of Allowability is courteously solicited. 



Respectfully submitted, 

Date: November 12, 2009 /Frankie W. Wong/ 

Frankie W. Wong 
Registration No. 61,832 
Patent Agent for Applicant 

McAndrews, Held & Malloy, Ltd. 
500 West Madison Street, 34th Floor 
Chicago, Illinois 60661 
(312) 775-8093 (FWW) 
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